\chapter{Solució proposada}

\section{Introducció}
Es proposa la solució que serà definida seguidament. En aquest capítol, però,
només es mostra la solució proposada a nivell conceptual. Per veure els detalls
de la implementació de la solució aquí proposada consulteu el següent capítol.\\

En el primer apartat s’explica la solució, conceptualment i a nivell global.
Seguidament es desglossa la solució en els diferents blocs funcionals que la
formen i s’exposa més detalladament quines són les funcionalitats que ha
d’assumir cada bloc, com ja s’ha dit, sense entrar en detalls tècnics.\\


\section{Proporcionar aplicacions que s’adapten di\-nà\-mi\-ca\-ment}
Es recorda que la solució ha de resoldre els punts llistats a continuació:\\

\begin{itemize}
  \item L’usuari ha d’acabar obtenint una aplicació adaptada i preparada per
  oferir adaptacions dinàmiques a les seves necessitats
  \item L’adaptació ha de ser ràpida
  \item L’adaptació s'ha de calcular de manera transparent a l’usuari
  \item L’aplicació de l’adaptació ha de ser el més còmode possible per l’usuari
  \item L’adaptació ha de millorar en cada proposta
  \item L’adaptació ha de poder-se desfer
  \item L’adaptació ha de tindre en compte tant el dispositiu com l’usuari
  \item L’adaptació ha de ser lo suficientment bona per a poder ignorar la
  majoria de problemes de hardware possibles
\end{itemize}

Tenint en compte els requisits anteriors, es proposa un sistema que rebi
aplicacions i sigui capaç de transformar les aplicacions que rep per fer-les
adaptables i adaptatives. Aquesta transformació consistirà en la injecció al
codi font de l’aplicació d’un bloc de codi especialment desenvolupat per a proporcionar
aquesta capacitat. Aquest bloc injectat, que l’anomenarem component client,
consta d’una part comuna per a qualsevol aplicació i plataforma i d’un mòdul que
extèn aquest component per a que pugui funcionar amb l’aplicació, la plataforma
i el dispositiu concrets als que està injectat.\\

Aquest bloc haurà de recollir dades tant de l’aplicació com de la interacció de
l’usuari amb la interfície gràfica de l’aplicació. Aquestes dades seran útils a
l’hora de proposar canvis a la interfície d’usuari. A més es proposa
l’utilització de perfils d’usuari i dispositiu per proporcionar encara més
dades. Quant més dades es puguin proporcionar al sistema millors propostes de
canvis poden ser generades. Mitjançant totes les dades de les que
disposi, el component servidor generarà propostes que seran oferides al
component client el pròxim cop que arrenqui l’aplicació per mostrar-les
finalment a l'usuari.\\

 \begin{figure}[H]
	\centering
	\includegraphics[width=1.0\textwidth]{imatges/chapter06/solucioProposada.png}
	\caption{Diagrama general de la solució proposada}
\end{figure}

La solució proposada es divideix en tres blocs.\\

El primer bloc, la Web, és l’encarregat de l’administració de tota la solució,
de recollir els diferents perfils, d’acceptar les aplicacions, afegir-hi el
component client i d’oferir-les a l’usuari final.\\

El segon bloc, el component client, està íntimament relacionat amb el tercer, el
component servidor. Ambdós treballen conjuntament per oferir a l’usuari final
una aplicació, obtinguda prèviament des de la Web, adaptada dinàmicament.\\

El component client s’encarrega de capturar la forma en que l’usuari interactua
amb la interfície d’usuari en forma de logs, enviar-los al component servidor,
adaptar la interfície amb els canvis proposats pel component servidor i recollir
feedback dels canvis realitzats. També s'encarrega d'oferir la funcionalitat
de poder seleccionar, d’un historial de propostes de canvis, quina d’elles
 s’utilitzarà.\\

El component servidor es limita a tractar els logs enviats des del client i el
feedback de l’usuari. Llavors a partir dels perfils d’usuari i dispositiu
ofereix propostes de canvis a la interfície, els quals els envia al client i
aquest s’ocupa d’aplicar-los si s’escau. La tasca de generar propostes de canvis
a la interfície d’usuari recau a la peça clau del sistema: el motor
d’inferència\footnote{Motor d'inferencia - S'explica en l'apartat 7.5.2}.\\

\section{Aplicació Web}
Per a poder dur a terme aquest punt de la solució, és a dir, per a recollir les
dades dels perfils inicials i l’aplicació, s’ha optat per utilitzar un servei
Web.\\

En la figura [FIGURA] es mostren tots els seus possibles casos d'ús
que també es detallen a continuació:\\

\begin{figure}[H]
	\centering
	\includegraphics[width=1\textwidth]{imatges/chapter06/web.png}
	\caption{Diagrama de casos d'us del bloc Web}
\end{figure}

\subsection{Funcionalitats}
A continuació s’expliquen detalladament cada una de les funcionalitats que  
recauen en aquest bloc:\\

\subsubsection{Gestionar usuaris}
Tot i que l’aplicació Web encara no ho controla del tot, el model de dades està
preparat perquè es pugui fer una gestió de l’usuari que esta connectat en sessió a
l’aplicació.\\

Així doncs, qualsevol usuari que es registri haurà de proporcionar en un
formulari si és administrador (per clarificar: administrador del discapacitat,
no el conegut ‘admin’ o ‘root’ de qualsevol sistema) o be el propi
discapacitat.\\

Aquest rol s’enmagatzema en persistència i s’utilitzarà en futures sessions per
determinar quines accions es poden dur a terme per l’interfície de l’aplicació Web.

\subsubsection{Gestionar perfils de dispositiu}
Es disposa en persistència d’una llarga extensió de perfils de dispositiu.
Aquests perfils contenen dades transparents a l’usuari necessàries per al
correcte funcionament del sistema indicant-li quines capacitats funcionals té el
dispositiu, ja sigui mòbil o d’escriptori.\\

Són fàcilment actualitzables ja que només cal actualitzar un fitxer XML de
tamany reduït. També se’n poden crear de nous creats per algú que hi entengui
editant aquest mateix fitxer.\\

A l’usuari se li mostrarà un llistat amb el nom de tots aquests dispositius
disponibles en persistència i haurà de seleccionar-ne un. Un cop seleccionat és
guardarà en persistència el perfil de dispositiu per a que l’utilitzin altres
funcionalitats del sistema o be per a poder-lo editar posteriorment.

\subsubsection{Gestionar perfils d'usuari}
Des de la Web s’han de poder definir doncs els perfils d’usuari. En el capítol 3
es mencionaven una serie de discapacitats. D’aquestes s’ha considerat que eren
aplicables pels objectius proposats pel sistema les discapacitats següents:\\

\begin{itemize}
  \item \textbf{Fisiques}\\Aquestes engloben limitacions de qualsevol combinació
  de: mobilitat d’extremitats superiors, mans o bé dits. El sistema distingeix entre
  extremitat, mà i dits esquerres o bé extremitat, mà i dits drets.
  \item \textbf{Visuals}\\Aquestes engloben limitacions visuals com ara
  daltonisme, pèrdua de visió o ceguera total. El sistema distingeix entre ull
  esquerra o ull dret.
  \item \textbf{Cognitives}\\Aquestes engloben discapacitats com problemes de
  salud mental, epilèpsia o bé falta de memòria.
\end{itemize}

A part de tota aquesta informació, també es requereix de l’entrada al sistema de
dades com el país de l’usuari i el sexe. Un cop les dades són guardades en
persistència s’anomenen perfil d’usuari, que modelitza en base de dades l’usuari
que utilitzarà les aplicacions a adaptar.\\

Aquest perfil serà utilitzat més endavant per altres funcions del sistema i
també pot ser utilitzar per a aprofitar perfils, és a dir, poder-lo seleccionar
d’un llistat en cas que l’usuari del qui es requereix la informació tingui un
perfil idèntic d’un altre usuari prèviament insertat.\\

Cal mencionar que una ampliació de les discapacitats acceptades seria
transparent a l’aplicació Web i al model de dades, limitant-se a actualitzar
certs registres d’aquest últim.

\subsubsection{Gestionar aplicacions}
Per tal de poder oferir aplicacions adaptades, aquestes aplicacions han de ser
prèviament definides al sistema. És necessari doncs omplir un formulari per tal
que el sistema tingui totes les dades que necessita per poder adaptar
l’aplicació.\\

Algunes de les dades més importants a entrar per l’usuari són:\\

\begin{itemize}
  \item L’aplicació amb el codi font
  \item Llibreria gràfica utilitzada per l’aplicació
  \item Versió Java de l’aplicació
  \item Plataforma de l’aplicació
  \item Directori de dins el paquet de on es troba el codi font
\end{itemize}

Un cop introduïdes totes les dades del formulari el sistema ho guardarà en
persistència com a perfil d’aplicació, que contindrà doncs l’aplicació en si i
totes les dades importants per al sistema.

\subsubsection{Injectar el component client a l’aplicació. Project Builder}
Es té la necessitat doncs de disposar d’un instal·lable el primer cop que
s’arrenca l’aplicació a adaptar.\\

La pròpia Web és capaç de compilar l’aplicació amb el component client injectat.
Llavors emmagatzema l’aplicació ja preparada amb el nou codi en persistència,
per tal de poder oferir-la a l’usuari mitjançant el gestor de descàrregues quan
aquesta és requerida.\\

En aquest codi injectat s’hi posarà també un fitxer de propietats amb metadades
per a que la comunicació entre client i servidor pugui dur-se a terme així com
l’identificació de l’adaptació el primer cop que es connecta.

\subsubsection{Gestionar regles del motor d’inferència}
El Motor d’Inferència necessita estar alimentat de regles. Aquestes regles han de ser introduïdes al sistema per
un administrador des de l’aplicació Web. Aquestes seran guardades en
persistència.\\

 Aquestes regles han de poder millorar-se mentre els usuaris van utilitzant
l’aplicació ja que quant més l’utilitzin més informació tindrà tant el sistema
com els administradors per tal de pensar nous canvis a fer.\\

Així doncs en qualsevol moment les regles prèviament definides poden ser
recuperades  i millorades mitjançant la selecció d’una d’elles en un llistat.

\subsubsection{Gestionar logs d’usuari}
Aquesta funcionalitat és bàsica pels administradors. Per tal de definir les
regles del motor d’inferència que determinaran canvis els administradors
necessiten consultar els logs que ha generat l’ús de les aplicacions, per poder
així estudiar-los i decidir quins canvis poden ser propicis i en quines
situacions.\\

A més l’estudi dels logs pot ajudar a identificar problemes d’usabilitat d’una
aplicació, descobrir problemes que sofreix un usuari concret, etc, ja que els
logs donen accés a informació tant de l’interfície d’usuari de l’aplicació com
de la forma en que els usuaris interactúen amb ella.\\

Així doncs la monitorització de logs és una peça clau a tres bandes, ja que
proporciona informació vital per extreure conclusions quant a la usabilitat de
les aplicacions, la eficàcia dels canvis realitzats a la interfície i els
usuaris que les utilitzen.\\

Més endavant s’explicarà el concepte de log d’una sessió de l’usuari en una 
aplicació. De moment n’hi ha prou en pensar que aquesta sessió esta
modelitzada en persistència  i que d’alguna manera el servidor ho enmagatzema.
Un cop aquesta informació és al servidor des de l’aplicació Web es permet
filtrar-los eficientment.\\

Algunes de les opcions de filtratge disponibles des del portal Web són:\\

\begin{itemize}
  \item Usuari del log
  \item Adaptació
  \item Tamany, color o propietats
  \item Events produits
  \item Temps entre pantalles
\end{itemize}

Totes les acotacions permeten l'ús dels operadors més importants de la
sintaxi SQL com {\tt >,<, !=, between, like} i més.\\

Un cop filtrats es poden visualitzar per pantalla o bé es poden descarregar en
format .txt per un estudi posterior.

\subsubsection{Gestionar adaptacions}
Pel model de dades una adaptació és un concepte que vincula una aplicació en
concret, amb un usuari en concret, amb un dispositiu en concret i amb un conjunt de
regles concret que proporcionaran propostes de canvi a la interfície d’usuari.
Llavors un cop introduides totes les dades d’aquests perfils, aquests s’engloben
en persistència en forma d’una adaptació única i identificativa. Aquest
identificador d’adaptació serà l’utilitzat pel sistema per totes les
funcionalitats.\\

Un usuari de la Web només podrà obtindre l’aplicació amb el codi injectat si
s’han introduït al sistema tots els perfils necessaris i per tant, existeix una
adaptació.\\

Els administradors han de poder editar i esborrar adaptacions previament
introduïdes al sistema per tal que els usuaris puguin gaudir de la resta de
funcionalitats que que proporciona l’aplicació Web.

\subsubsection{Descarregar aplicacions adaptades}
Els usuaris tindran accés a una llista amb totes les aplicacions que tenen una
adaptació pensada per ells en concret. El sistema facilita la descàrrega de
l’aplicació adaptada mitjançant aquesta funcionalitat.\\

Aquesta funcionalitat esta disponible des de que s’ha completat el registre de
l’aplicació com en les successives adaptacions que s’hi van produint.

\subsubsection{Funcionalitats menors}

Es consideren funcionalitats menors aquelles que no aporten cap solució als
requisits del problema, però que enriqueixen l’experiència de la utilització de
la Web.\\

\begin{itemize}
  \item \textbf{Publicació / Presentació de notícies}\\El sistema proporciona
  les eines necessàries per crear / publicar notícies, en una estructura semblant a la d’un weblog.
  \item \textbf{Accés a la documentació del sistema}\\Aquesta funcionalitat
  resulta molt útil especialment per als administradors.\\
  
  Donat que la solució que es proposa és tan tècnica com conceptualment
  complexa s’ofereix a l’usuari de la Web múltiples fonts de documentació que
  poden ajudar-li a millorar l'experiència amb el sistema.\\
  Aquesta documentació es fa especialment útil per utilitzar la funcionalitat
  de la definició de regles pel motor d’inferència, ja que els administradors
  no tenen perquè conèixer els funcionaments interns del sistema, ni del motor
  d’inferència que implementi la solució, ni de com el motor d’inferència té
  accés a les dades requerides per les regles.\\
  
  Així amb aquesta documentació s’estableix un pont entre l’administrador i les
  funcionalitats que ha de utilitzar.\\
  
  També hi és disponible aquest document.
  \item \textbf{Paginació}\\Tots els llistats són paginables per índex per a
  poder-los fer més usables per l’usuari, ja que redueix el temps d’espera i la navegació
\end{itemize}


\subsection{Disseny de la Web}
S’ha optat per un diseny minimalista en quant a colors i figures. Tot suavitzat
amb contorns arrodonits.\\

La disposició de la informació en pantalla es divideix en tres blocs:\\

\begin{itemize}
  \item \textbf{Capçalera}\\Conté el banner i el menú superior. En el menú
  superior es troben ubicades accions que poden utilitzar usuaris no
  registrats com ara notícies, descàrregues i un \emph{quant a}.
  \item \textbf{Menú esquerra}\\Varia segons si l’usuari s’ha autenticat al
  sistema o no. Inicialment s’hi mostra el formulari d'autenticació, es dóna la
  opció de registrar-se com a nou usuari del sistema. Un cop autenticat l’usuari, el menú
  mostra les accions d’adaptacions, perfils d’usuari, perfils de dispositiu i
  logs.
  \item \textbf{Cos}\\És on s’hi mostren els resultats de les accions tant del
  menú esquerra com el menú superior.
\end{itemize}


A continuació és mostren vàries captures de les funcionalitats prèviament
definides quedant així constància tant del disseny com de l'aplicació de cada
cas d'ús.

\begin{figure}[H]
	\centering
	\includegraphics[width=0.8\textwidth]{imatges/gestiousuaris.png}
	\caption{Gestió d'usuaris}
\end{figure}

\begin{figure}[H]
	\centering
	\includegraphics[width=0.8\textwidth]{imatges/gestioadaptacions.png}
	\caption{Gestió d'adaptacions. Llistat}
\end{figure}

\begin{figure}[H]
	\centering
	\includegraphics[width=0.8\textwidth]{imatges/defineadaptation.png}
	\caption{Gestió d'adaptacions. Definició.}
\end{figure}

\begin{figure}[H]
	\centering
	\includegraphics[width=0.8\textwidth]{imatges/definicioaplicacio.png}
	\caption{Gestió d'aplicacions}
\end{figure}
\begin{figure}[H]
	\centering
	\includegraphics[width=0.8\textwidth]{imatges/gestiologs.png}
	\caption{Gestió de logs}
\end{figure}
\begin{figure}[H]
	\centering
	\includegraphics[width=0.8\textwidth]{imatges/perfilusuario2.png}
	\caption{Gestió de perfil d'usuari. Llistat}
\end{figure}

\begin{figure}[H]
	\centering
	\includegraphics[width=0.8\textwidth]{imatges/perfilusuario.png}
	\caption{Gestió de perfil d'usuari. Creació}
\end{figure}

\begin{figure}[H]
	\centering
	\includegraphics[width=0.8\textwidth]{imatges/defincioregla.png}
	\caption{Definició de regles}
\end{figure}



\section{Component client}
El component client és la part de la solució que esta desplegada en el
dispositiu de l’usuari. S’encarrega de monitoritzar les accions d’usuari i
aspectes de l’aplicació per nodrir el motor d’inferència.\\

Així mateix també adapta la interfície d’usuari de l'aplicació amb els canvis
proposats pel component servidor sempre i quan
l’usuari els accepti a l’arrancar l’aplicació.\\
  
Opcionalment recull \emph{feedback} dels canvis aplicats a la interfície
d’usuari.\\

\begin{figure}[H]
	\centering
	\includegraphics[width=1\textwidth]{imatges/chapter06/logControllerTimeline.png}
	\caption{Recull de logs}
\end{figure}

\begin{figure}[H]
	\centering
	\includegraphics[width=1\textwidth]{imatges/chapter06/FrameworkClientAspectes.png}
	\caption{Adaptació de la interfície d'usuari}
\end{figure}

\subsection{Funcionalitats}
A continuació s’expliquen detalladament les funcionalitats que recauen a aquest
bloc:\\

\subsubsection{Monitoritzar el cicle d’aplicació}
Quan l’usuari arrenca l’aplicació el component client intercepta la càrrega i
abans de que es mostri la primera pantalla, comprova en la persistència del
dispositiu si existeixen adaptacions prèvies. En cas de que n’hi hagi, es crea
una pantalla.\\

El component client intercepta i logueja els mètodes de creació de l’aplicació i
el de destrucció. A més també es pot enregistrar quan l’aplicació es pausa (en
el cas d’aplicacions per a mòbils) o quan es minimitza / entra en segon pla (en
cas d’aplicacions d’escriptori). Aquesta informació és indispensable per tal de
que altres funcionalitats que s’explicaran posteriorment es puguin dur a
terme.\\

A més també pot ser útil per a optimitzar algunes regles, ja que pot ser que un
temps d’espera que un administrador consideri excessiu per realitzar una tasca
sigui el resultat d’una trucada entrant, per exemple.

\subsubsection{Monitoritzar l’interfície d’usuari}
El component client té accés a tota la interfície d’usuari de l’aplicació i
codifica la seva estructura en el log que es va omplint durant la sessió. Això
implica que es monitoritzin totes les finestres , tots els components, totes les
fonts, totes les imatges, etc.\\

Segons quina llibreria gràfica utilitza l’aplicació, el component client
disposarà d’un mòdul específic per aquesta per tal de poder dur a terme aquesta
codificació correctament. El sistema ha modelitzat l’estructura del log tal i
com s'especifica en el protocol de comunicació explicat posteriorment, tot i que
és ampliable. Per tant cada llibreria gràfica ha de disposar d’una implementació concreta d’aquest mòdul i l’estructura de les dades que recull han d’acabar essent la mateixa per a
qualsevol llibreria gràfica.\\

D’aquesta manera en el servidor es disposarà d’una única representació de logs
d’interficie d’usuari  independent de la llibreria gràfica, facilitant així els
seus mecanismes, com el motor d’inferència o la monitorització i descàrrega de
logs, i brindant-los una visió abstracta i genèrica de log per a qualsevol
llibreria gràfica.

\subsubsection{Monitoritzar les accions d’usuari}
Cada interacció de l’usuari amb l’aplicació queda monitoritzada en forma de log.
Aquest recull de dades consisteix en calcular els intervals de temps entre acció i acció, com podria ser entre event i event. També es recullen els events  relacionats amb la llibreria gràfica que s’utilitza. Les accions d’usuari també estan vinculades quasi totalment a la llibreria
gràfica que empra l’aplicació.\\

De la mateixa manera que el recull de dades de l’interficie d’usuari, les
accions d’usuari es registren en un format completament abstracte respecte a la
llibreria gràfica emprada facilitant el seu tractament al servidor.\\

Les accions d’usuari són les dades principals de que es disposaran a l’hora
d’escriure regles pel motor d’inferència. Així és important intentar recollir
quantes més dades d’aquest tipus millor.

\subsubsection{Seleccionar recull de canvis a aplicar}
Conforme el component servidor va proposant reculls de canvis al component
client, l’usuari ha de poder escollir quin recull de canvis vol aplicar a
l’aplicació. S’ha decidit que el moment idoni per a escollir-ho sigui l’inici de
l’aplicació, ja que així els canvis són els mateixos durant tota la
sessió, facilitant la coherència per l’usuari en tot moment.\\

La selecció de
recull de canvis a aplicar es proposa en forma de llista ordenada, essent més
prioritaris els que l’usuari té en millor consideració, és a dir, ordenats o bé
per feedback o bé pel nombre de vegades que l’usuari l’ha seleccionat. També
fòra bo, però, que l’última proposta de canvi tingui prioritat sobre qualsevol
altra.

\subsubsection{Seleccionar feedback dels canvis aplicats}
Opcionalment el sistema suporta la puntuació de la satisfacció de l’usuari
respecte a un recull de canvis concret. Per tal de recollir el major nombre
possible de puntuacions s’ha decidit que en comptes d'incorporar-ho a la Web,
sigui el component client qui demani el feedback a l’usuari, integrant-se així
en el cicle d’ús de l’aplicació.\\

S’ha decidit que el millor moment per demanar
aquest feedback sigui quan l’aplicació es tanqui, ja que llavors tindrà
probablement la opinió més objectiva possible respecte dels canvis que tot just
ha disfrutat. Si no s’havia aplicat cap canvi l’usuari també té la posibilitat
de puntuar l’ús de l’aplicació sense haver sigut alterada, ja que aquesta nota
pot servir com a referència amb la que comparar les posteriors puntuacions dels
diferents canvis que es vagin aplicant.

\subsubsection{Adaptar la interfície d’usuari}
Les principals funcionalitats del component client són dos: s’ha vist que la
primera era la monitorització de varis aspectes necessaris tant de l’aplicació
com d’accions d’usuari. La segona és sens dubte l’aplicació dels canvis a la interfície d’usuari. Per tal d’aplicar els canvis el component client necessita novament d’un mòdul
concret per poder interactuar amb la llibreria gràfica que utilitzi
l’aplicació.\\

Els canvis s’apliquen en quant l’usuari escull un dels reculls de propostes de
canvis. Si l’usuari no en selecciona cap o el component client encara no en
disposa de cap aquesta funcionalitat es desactiva fins el proper cop que
s’iniciï l’aplicació.

\subsubsection{Enviar logs al component servidor}
Els logs generats pel mòdul de monitorització han de ser enviats al servidor
tard o d’hora per a que el component servidor disposi de quanta més informació
millor per a proposar canvis. El moment en que s’envien els logs es deixa en
mans de la implementació, ja que segons la plataforma, el dispositiu i el moment
d’ús el moment més favorable per enviar dades pot variar enormement.\\

De totes formes els logs han de ser emmagatzemats en una persistència local (és
a dir, al dispositiu on s’han capturat) fins que no es pot garantir que aquests
han arribat correctament al component servidor. Un cop es puguin enviar al
servidor, el component client accedirà a aquesta persistència i enviarà els logs
al servidor.

\subsubsection{Rebre propostes de canvis del component servidor}
En un moment o altre, el component client ha de obtindre dades del component
servidor, especificant nous reculls de propostes de canvis a aplicar.\\
Com ja s’ha explicat al punt anterior, el moment de connexió amb el component
servidor es deixa en mans de la implementació. Per exemple, en l’implementació
per a dispositius mòbils s’ha optat per a que sigui a l’inici de l’aplicació, mostrant una pantalla de selecció de canvis.
Aquesta pantalla mostra un petit historial de les últimes propostes puntuades
pel feedback de l’usuari, deixant sempre l'opció d'escollir
l'aplicació original i mostrant com a segona opció la nova proposta en cas
d'existir.


\section{Component servidor}
El component servidor és el bloc que mitjançant la informació proporcionada pel
component client i els perfils guardats en persistència, recollits per la Web,
genera propostes d’adaptació per un usuari, dispositiu i aplicació en
concrets.\\

\begin{figure}[H]
	\centering
	\includegraphics[width=0.8\textwidth]{imatges/chapter06/frameworkServidor.png}
	\caption{Diagrama del component servidor}
\end{figure}

\subsection{Funcionalitats}
A continuació s’expliquen detalladament les funcionalitats que recauen a aquest
bloc:\\

\subsubsection{Rebre logs del component client}
Aquest bloc ha de recollir els logs preparats pel component client i
emmagatzemar-los persistentment. A més ha de notificar d’alguna manera al
component client que ha rebut correctament els logs per a que aquest pugui
esborrar-los de la seva persistència local. Cal remarcar que, així com el
component client pot permetre’s el luxe d’emmagatzemar els logs en format cru,
el component servidor ha d’emmagatzemar-los de forma estructurada ja que
posteriorment hauran de ser consultats tant pel mateix component servidor, a
l’hora de generar propostes de canvi, com per la Web, per tal de poder, per exemple, poder-los filtrar i mostrar-los a un administrador.

\subsubsection{Generar propostes de canvis a la interfície d’usuari}
Per tal de poder generar propostes de canvi a la interfície d’usuari, el
component client fa ús d’un component software anomentat {\em Motor
d’Inferència}. Aquest component, que s’explica amb més detall seguidament, es
pot entendre com una caixa negra on, a partir d’unes dades d’entrada es generen unes dades de
sortida, tenint en compte unes regles. Aquestes regles són les que ha
d’introduir l’administrador per cada adaptació, via Web.\\

Quant a les dades d’entrada que s’han de proporcionar al Motor d’inferència per
obtenir una proposta de canvis a la interfície d’usuari per a una adaptació
concreta tenim les següents:\\

\begin{itemize}
  \item Regles associades a l’adaptació
  \item Logs associats a l’adaptació (que inclouen tant la definició de la
  interfície d’usuari com les accions que ha realitzat l’usuari sobre la mateixa)
  \item Perfil d’usuari
  \item Perfil de dispositiu
  \item Canvis proposats anteriorment, amb el seu feedback corresponent
\end{itemize}

\subsubsection{Enviar propostes de canvi al component client}
Les respostes que s’han generat han de ser enviades al component client per tal
que l’usuari es pugui beneficiar d’elles, així com jutjar-les.


\subsection{El Motor d’Inferència}
Al camp de l’intel·ligència artificial, un \emph{Sistema
Expert}\footnote{Sistema Expert - http://es.wikipedia.org/wiki/Sistema\_experto}
és un component software que intenta deduir conclusions a partir d’una base de coneixement. Una base de coneixement no és més que un conjunt de dades degudament codificat i introduït en un sistema informàtic. Un motor d’inferència és un sistema expert que, per tal de deduir conclusions, ho fa a través d’un conjunt de regles que han de ser introduïdes al sistema.\\

Les regles són expressions en llenguatge formal que són activades per elements concrets de la base de coneixement (especificats a la mateixa regla) i provoquen l’activació d’altres regles així com la definició (o alteració) de conclusions que retornarà el motor d’inferència.
Les regles es podrien definir d’una forma més vulgar com mètodes de codi que no
poden ser cridats, sinó que el sistema executa quan existeixen uns elements
concrets amb un estat concret (especificat a la pròpia regla) a la base de
coneixement.\\

Cal destacar doncs que les regles s’executaran tants cops com elements amb
l’estat adequat existeixin a la base de dades, però també s’executaran quan una
altra regla modifiqui un element portant-lo a un estat que coincideixi amb el
definit a l’activació de la regla.
